Malaysia Server Name Directory A Standardized Naming Process That Facilitates Team Collaboration

standardized naming can significantly improve team collaboration efficiency. through unified rules, operation and maintenance, development and security teams can quickly identify the server's region (such as my-kl) , environment (prod/dev/test) , service type (web/db) and the team to which it belongs, reducing communication costs and human errors, while facilitating indexing and aggregation in cmdb, monitoring and automation scripts.

in addition, standardized naming is crucial for automated deployment, permission management, and troubleshooting. it can be used with ci/cd and iac tools for mandatory verification to improve change traceability.

it is recommended to include the following core elements and splice them in a fixed order: country/city code (such as my-kl, my-pg), environment (prod/stg/dev), service type (web/app/db/cache), role or function (frontend/backend), and serial number (two or three digits).

example pattern: my-kl-prod-web-fe-01 . consistently use dashes as separators, all lowercase or all uppercase, and clearly define code dictionaries and reserved words in team specifications.

recommended processes include: 1) convene a multi-team review and define naming dictionaries and templates; 2) establish a naming registration table and uniqueness verification in the cmdb; 3) encode naming rules into iac and ci processes (such as terraform/ansible module verification); 4) migrate existing resources in stages and retain aliases; 5) establish a change approval and version recording mechanism.

during implementation, documentation and training should be emphasized, a naming administrator role should be set up to be responsible for conflict resolution, and naming rules should be enforced on new instances through automated scripts to ensure consistency from the source.

example 1: my-kl-prod-web-01 — my (country abbreviation), kl (kuala lumpur), prod (production), web (service type), 01 (serial number).

example 2: my-pg-stg-db-02 — my(malaysia), pg(penang), stg(pre-release), db(database), 02(copy number).

example three: my-jb-dev-app-be-01 — jb (johor), dev (development), app (application), be (backend), 01 (instance number).

example 4 (hybrid cloud/hosting): my-kl-prod-web-aws-01 — add cloud provider or hosting id to the rule to facilitate cross-platform management.

recommendations for migration steps: first do a complete asset inventory and do old name-new name mapping in the cmdb, and rename in batches according to business boundaries; use dns aliases or load balancers to block immediate name changes for external dependencies; update the target labels of monitoring, alarm, and backup policies at the same time.

in terms of maintenance, naming specifications should be written into sops and integrated into the new process, automated checks should be used to prevent non-compliant creations, regular audits should be carried out, and corrections and communication records should be implemented by the naming administrator when conflicts occur.